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DETAILED ACTION 

1 . This FINAL action is responsive to the amendment filed on March 02, 2006. 

2. Claims 1-2, 4-19 and 21-32 are pending. Claims 3 and 20 have been canceled. 
Claims 1 and 19 are independent claims. 

Withdrawn Objections 

3. The Objection to the specification has been withdrawn. 

Claim Objections 

4. Claims 4 and 23 are objected to because of the following informalities: Claim 4 
describes a method of claims 2 or 3, however since claim 3 has been canceled it should 
depend on claim 2, claim 23 has similar problem. Appropriate correction is required. 



Claim Rejections - 35 USC § 102 
5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in a patent granted on an application for patent by another filed in the 
United States before the invention thereof by the applicant for patent, or on an international application 
by another who has fulfilled the requirements of paragraphs (1), (2), and (4) of section 371(c) of this 
title before the invention thereof by the applicant for patent. 
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6. Claims 1-2, 4-7, 9-17, 19, 21-26, 30 & 32 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Yehia (U.S. Pub 2002/0147726, filed March 20, 2002). 

Regarding Independent claim 1, Yehia discloses a method for the automatic 
generation of message validation and/or transformation software from message 
interface specifications and business rules for use in a message processing 
system comprising the steps of: 

• Inputting a set of message definitions, data dictionary entries and/or 
business rules using a structured editor to create a set of structured files 
that define the message interface and/or business rules (paragraph 23 & 
85, wherein an interface allows input for rules for the data and rules 
analysis engine that include business rules. The interface guides the user 
in defining the rules and rule data. The compilation component compiles 
the rules and rule data into an XML XSL based rule language therefore 
providing a set of structured files that define the message interface or 
business rules); 

• Generating message validation software from the set of structured files 
(paragraphs 270, 272 & 279, wherein client validation and enforcing 
business rules at front-end applications are performed from the set of 
structured files represented within XML documents. The structured xml 
files are used to perform rule validation); 

• Generating message transformation software from the set of structured 
files (paragraph 94, wherein the action processor is used with the analysis 
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engine for processing actions pertaining to messages. Software 
components are developed to address the received actions and include 
structured files since they are described using XML). 
• Storing the message validation and transformation software in one or 
more databases for use by the message processing system (paragraph 
279, wherein the client validation creation and distribution is stored within 
a database). 

Regarding Dependent claim 2, with dependency of claim 1, Yehia discloses 
wherein the set of message definitions and data dictionary entries can be reused 
to develop additional message definitions, dictionary entries and/or business 
rules across an enterprise (paragraph 92, wherein the use of XML enables 
maximal reuse of information and data through the composition of XML 
fragments. The message definitions and data dictionary entries defined within the 
structured files are reused because they are described using XML). 

Regarding Dependent claim 4, with dependency of claim 2,Yehia discloses 
wherein the structured files are in the XML format (paragraph 22, wherein the 
invention uses standard XML notations to define rules and standard XSL and 
XSLT processing instructions to enforce rules. Therefore the structured files used 
to represent the business rules are described using XML). 
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Regarding Dependent claim 5, with dependency of claim 4, Yehia discloses 
wherein the generation of message transformation software and message 
validation software further comprises the step of translating the structured files in 
the XML format into Extensible Stylesheet Language Transforms (XSLT) 
(paragraph 22, wherein the invention uses standard XML notations to define 
rules and standard XSL and XSLT processing instructions to enforce rules. 
Therefore the structured XML files are translated into XSLT). 

Regarding Dependent claim 6, with dependency of claim 1, Yehia discloses 
wherein the step of generating message validation software further comprises 
the step of inputting the structured files into a schema generator in order to 
generate a set of W3CXML Schema to be used to validate messages 
(paragraphs 97,101 & 195 wherein the schema details the relationship between 
members and objects. The schema shows the relation between orders and 
services being ordered. The same relation is carried through the XML fragments. 
In addition the XML document values are mapped into the schema for validation). 

Regarding Dependent claim 7, with dependency of claim 1 , Yehia discloses 
wherein the step of inputting further comprises the step of validating the 
structured files to ensure the structured files conform to a pre-determined 
structure (paragraph 23, wherein the GUI guides the user in defining the rules 
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and rule data, therefore the structured files must conform to a pre-determined 
structure). 

Regarding Dependent claim 9, with dependency of claim 1 , Yehia discloses 
wherein the structured files are presented to the user in HTML (paragraph 1 38, 
wherein one control produces satisfactory results is scripts embedded in HTML 
pages. The control is used to help facilitate the negotiation process, therefore the 
structured files are presented to the user in HTML format to display and help 
guide the negotiation process). 

Regarding Dependent claim 10, with dependency of claim 9, Yehia discloses 
wherein the structured rule editor uses a web browser to present the HTML to the 
user (paragraph 186, wherein the client connector includes only a browser based 
GUI that communicates directly with a web server at the hub. The GUI 
representing the structured rules editor uses the web browser to communicate 
thereby presenting the HTML to the user). 

Regarding Dependent claim 11, with dependency of claim 1 , Yehia discloses 
producing a report detailing differences between two sets of structured files 
(paragraph 130, wherein the invention checks all related contracts, verifies and 
analyzes the effect and alerts the member about any potential conflict. Therefore 
it is inherent that it identifies any differences between the structured files since it 
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verifies and alerts the user if differences exist between the structured files 
representing the contracts). 

Regarding Dependent claim 12, with dependency of claim 6, Yehia discloses 
modifying the structured files after generating the XML schema in order to correct 
errors identified by the schema generator (paragraph 196-198 & 230, wherein a 
rule entity schema is used with an analysis engine to retrieve rules, rule 
parameters, actions and pointers. Therefore the GUI allows the user to update 
any errors by making changes to the rules once the rule entity schema indicates 
errors. A schema template is used to save the updated information). 

Regarding Dependent claim 13, with dependency of claim 6, Yehia discloses 
inputting the set of interface schemas into a schema validator to determine if the 
generated schemas are correctly formatted and consistent (paragraphs 101 & 
103, wherein the rules analyzer determines if the generated schema from the 
database are correctly formatted and consistent). 

Regarding Dependent claim 14, Yehia discloses modifying the structured files 
after validating the schema in order to correct errors identified by the schema 
validator (paragraph 270, wherein the rule handler is used to validate the 
structured files from the schema database). 
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Regarding Dependent claim 15, with dependency of claim 1, Yehia discloses 
transferring pre-existing word processing formatted business rule documents into 
structured files (paragraph 145, wherein templates that include formatted 
business rules within word documents are supported by the invention). 

Regarding Dependent claim 16, with dependency of claim 6, Yehia discloses 
importing from existing W3C XML Schema files into a set of structured files 
(paragraphs 92,101 &1 18, wherein the templates are built using XML once the 
data elements are extracted from the parser. The database used to store them 
represents the XML schema files and they are used for building contract 
templates according to the W3C standard). 

Regarding Dependent claim 17, with dependency of claim 15, Yehia discloses 

• Translating the word processing formatted document into an XML 
formatted document (paragraphs 145 & 146, wherein the word document 
with headers specifying the contract clause titles is translated into XML 
format using XSL); 

• Parsing the XML formatted document to identify unparseable constructs 
and errors (paragraphs 148 & 197, wherein the parser is used to retrieve 
the contents of specific XML tags, those that describe the metadata of the 
contract. Therefore the XML document is parsed to identify unparseable 
constructs and errors by using the data and rules analysis engine); 
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• Presenting the unparseable constructs and errors to the requirements 
engineer for modification (paragraph 99, wherein the parser is used in 
conjunction with the rules analysis engine, therefore if unparseable 
constructs and errors exist they are modified via GUI that modify the rules 
engine); 

• Rewriting the unparseable constructs into a structured construct using the 
structured rule editor (paragraphs 92 & 93, wherein the unparseable 
constructs identified by the rules analysis engine are modified using the 
GUI or structured rule editor); 

• And, repeating the parsing, presenting and rewriting steps until all 
unparseable constructs and errors are substantially eliminated 
(paragraphs 92 & 93, wherein once the rules are modified within the GUI 
they are parsed again using the structured document template). 

Regarding Independent claim 19, Yehia discloses a system for the automatic 
generation of message validation software and/or transformation software from 
business rules for use in a message processing system comprising: 

• A structured editor for inputting a set of message definitions, data 
dictionary entries and business rules to form a set of structured files that 
defines the message interface as a set of nested elements and groups of 
elements and business rules (paragraph 23 & 85, wherein an interface 
allows input for rules for the data and rules analysis engine that include 
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business rules. The interface guides the user in defining the rules and rule 
data. The compilation component compiles the rules and rule data into an 
XML XSL based rule language therefore providing a set of structured files 
that define the message interface or business rules); 

• Means for generating message validation software and message 
transformation software from the structured files (paragraph 94, 270, 272 
& 279, wherein the action processor is used with the analysis engine for 
processing actions pertaining to messages. Software components are 
developed to address the received actions and include structured files 
since they are described using XML. Wherein client validation and 
enforcing business rules at front-end applications are performed from the 
set of structured files represented within XML documents. The structured 
xml files are used to perform rule validation). 

• Storage means for storing the message validation and transformation 
software in one or more databases for use by the message processing 
system (paragraph 279, wherein the client validation creation and 
distribution is stored within a database). 



Regarding Dependent claim 21, with dependency of claim 19, the claim is for a 
computer system performing the method of claim 2, and is similarly rejected 
under the same rationale. 
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Regarding Dependent claim 22, with dependency of claim 19, Yehia discloses 
wherein the means for generating the schema inputs to message validation 
software from the structured files is an XML schema generator (paragraphs 
97,101 & 195 wherein the schema details the relationship between members and 
objects. The schema shows the relation between orders and services being 
ordered. The same relation is carried through the XML fragments. In addition the 
XML document values are mapped into the schema for validation). 

Regarding Dependent claim 23, with dependency of claim 19, the claim is for a 
computer system performing the method of claim 5, and is similarly rejected 
under the same rationale. 

Regarding Dependent claim 24, with dependency of claim 19, Yehia discloses 
wherein the structured editor comprises a means for constraining the inputs into 
the structured files to ensure the structured files conform to a pre-determined 
structure and content (paragraph 23, wherein the GUI guides the user in defining 
the rules and rule data, therefore the structured files must conform to a pre- 
determined structure and content). 

Regarding Dependent claim 25, with dependency of claim 19, Yehia discloses 
wherein the structured editor comprises a graphical user interface for editing the 
structured files in a tabular non-XML format (paragraph 23, wherein a structured 
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editor represented by a graphical user interface is used for editing the structured 
files that represent templates and include documents in a tabular fashion). 

Regarding Dependent claim 26, with dependency of claim 24, Yehia discloses 
wherein the structured editor limits the selection of attributes available to a user 
during definition of an element, group of elements or rule (paragraph 23, wherein 
the framework determines the absence of an attribute, retrieves the rule 
definition, applies the rule handler, and returns the success or failure codes). 

Regarding Dependent claim 30, with dependency of claim 19, Yehia discloses 
wherein the structured editor is a table editor which enables the user to input 
tables selected from the group consisting of: Message Definition Tables, Data 
Dictionary Tables, Business Rule Tables, Error Tables, Variable Definition 
Tables, and Requirements Trace Matrix Tables (paragraph 23, it is inherent that 
the structured editor is capable of supporting table inputs since it guides the user 
in defining the rules which are then stored within a schema database in a tabular 
format). 

Regarding Dependent claim 32, with dependency of claim 19, Yehia discloses 
compare tool for comparing a first structured file or document with a second 
structured file or document in order to develop a list of differences between such 
files or documents (paragraph 130, wherein the invention checks all related 
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contracts, verifies and analyzes the effect and alerts the member about any 
potential conflict. Therefore it is inherent that it identifies any differences between 
the structured files since it verifies and alerts the user if differences exist between 
the structured files representing the contracts, The member is alerted when 
differences between the contracts exist, therefore a list showing the differences is 
inherently present). 

Claim Rejections ■ 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

8. Claims 8, 18, 29 & 31 remain rejected under 35 U.S.C. 103(a) as being 
unpatentable over Yehia (U.S. Pub 2002/0147726, filed March 20, 2002) in view of 
Abrari (U.S. Pub 2002/0120917, filed Nov 26, 2001). 

Regarding Dependent claim 8, with dependency of claim 1 , Yehia teaches the 
creation and representation of business rule definitions using standard XML 
notation. The creation of the business rules is accomplished using a graphical 
user interface with a compilation component. The interface guides the user for 
defining the rules and data associated with the rules. However Yehia fails to 
explicitly teach an editor for editing structured files in a tabular format 
(paragraphs 21 , 22 & 23). Abrari teaches wherein the structured editor provides a 
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graphical user interface to the requirements engineer for editing the structured 
files in a tabular format (figures 6-17, wherein a tabular format is shown within 
the graphical user interface for editing the structured files). Yehia and Abrari are 
analogous art because they are from the same field of endeavor of development 
of Business rule applications. At the time of the invention it would have been 
obvious to a person of ordinary skill in the art to include a tabular format within a 
GUI for editing structured files. The motivation for doing so would have been to 
allow easier updating and manipulation of programmed code by making changes 
within a GUI showing the code in a tabular format. Therefore it would have been 
obvious to combine the teachings of Abrari with Yehia for the benefits of allowing 
flexible code manipulation by changing structured files using a GUI representing 
code in a tabular format. 

Regarding Dependent claim 18, with dependency of claim 1, Yehia fails to 
explicitly teach the generation of test cases for testing the business rule 
definitions used for message validation (paragraphs 21, 22 & 23). Abrari teaches 
generating a set of test cases to provide test messages with which to test the 
message transformation and message validation software (paragraph 1 1,47 & 42 
wherein the platform separates business rules from procedural business process 
logic and thereby improving code quality and reducing development costs. In 
addition the platform enables non-technical personnel to develop, test, deploy 
and update business rules without programming. Therefore it is inherent that 
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testing includes generating test cases to test the message validation software). 
Yehia and Abrari are analogous art because they are from the same field of 
endeavor of development of Business rule applications. At the time of the 
invention it would have been obvious to a person of ordinary skill in the art to 
include the testing of the message validation software by preparing test cases. 
The motivation for doing so would have been to minimize errors thereby 
improving code quality by testing the business rules using test messages. 
Therefore it would have been obvious to combine the teachings of Abrari with 
Yehia for the benefits of allowing testing of messages for improving code quality 
thereby reducing development and maintenance costs. 

Regarding Dependent claim 29, with dependency of claim 19, Yehia fails to 
teach a project interface to access all the structured files. Abrari teaches a 
project interface for providing access to the user of all structured files used to 
define the project and access to all functions that can be performed on such files 
(paragraph 42, 43 & 46 wherein building and testing involves the entire project 
cycle. In addition business rules developed early in the development process are 
incorporated into the final application. It is inherently present that the user has 
access to all components for the development of the project including attributes, 
building, testing and user interface development. This is represented by the tree 
view). Yehia and Abrari are analogous art because they are from the same field 
of endeavor of development of Business rule applications. At the time of the 
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invention it would have been obvious to a person of ordinary skill in the art to 
allow a user to have access to all the structured files for project development. 
The motivation for doing so would have been to lower personnel costs and 
increase profits by providing an integrated and dynamic platform for application 
development. Therefore it would have been obvious to combine the teachings of 
Abrari with Yehia for the benefits of allowing an integrated set of tools for the 
development, deployment and maintenance of applications within a platform. 

Regarding Dependent claim 31, with dependency of claim 19, Yehia fails to 
teach a document generator to develop user-readable documentation pertaining 
to the message definition interface and business rules. Abrari teaches a 
document generator for generating user-readable documentation specifying the 
message definition interface and business rules (paragraph 42, wherein the 
methodology guarantees that UML-conforming documentation such as case 
models will be created as an inherent byproduct of the software development 
process. Therefore a document is generated specifying the message definition 
interface and business rules since they are part of the application represented by 
the document). Yehia and Abrari are analogous art because they are from the 
same field of endeavor of development of Business rule applications. At the time 
of the invention it would have been obvious to a person of ordinary skill in the art 
to include documentation specifying the message definitions and business rules. 
The motivation for doing so would have been to provide a more updated platform 
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with business rules. Therefore it would have been obvious to combine the 
teachings of Abrari with Yehia for the benefits of allowing a dynamic platform 
capable of generating documentation specifying business rules and message 
definition interface. 

9. Claims 27 & 28 remain rejected under 35 U.S.C. 103(a) as being unpatentable 
over Yehia (U.S. Pub 2002/0147726, filed March 20, 2002) in view of Tomm (U.S. 
6,560,608, filed Jun 9, 2000). 

Regarding Dependent claim 27, with dependency of claim 19, Yehia 
teaches the creation and representation of business rule definitions using 
standard XML notation. The creation of the business rules is accomplished using 
a graphical user interface with a compilation component. The interface guides the 
user for defining the rules and data associated with the rules. However Yehia 
fails to explicitly teach the generation of an index listing of elements used in a 
definition (paragraphs 21 , 22 & 23). Tomm teaches means for generating an 
index listing of all elements used in an interface definition, cross referencing 
entries within data dictionaries with their appearances within message definitions 
(See figure 4, column 4, lines 23-50, wherein synonyms dictionary has 
corresponding set of synonyms where each synonym corresponds to a data field 
for a given format. Therefore the index listing is part of the synonym dictionary 
since it relates to a data field). At the time of the invention it would have been 
obvious to a person of ordinary skill in the art to include an index listing of 
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elements. The motivation for doing so would have been to provide mapping of 
data dictionaries by accessing an index listing thereby allowing rules to be more 
easily manipulated. Therefore it would have been obvious to combine the 
teachings of Yehia with Tomm for the benefits of eliminating the error-prone and 
tiresome process of entering the procedure manually each time it is needed by 
providing an index listing used to map dictionary data. 

Regarding Dependent claim 28, with dependency of claim 19, Yehia fails to 
teach the use of a data dictionary capable of providing changes pertaining to only 
the interface definitions. Tomm teaches means for pruning a data dictionary into 
a data dictionary that comprises only those elements and/or group of elements 
that are used in a message interface definition (column 5, lines 25-42, wherein 
the rules dictionary is searched for rules matching the signature, if no rule 
matches an editor allows the user to create a rule. The rules or elements are 
defined using the editor which inherently includes removal of definitions from the 
dictionary or modifying the dictionary to only show elements pertaining to the 
message interface definition). At the time of the invention it would have been 
obvious to a person of ordinary skill in the art to include the removal/manipulation 
of rules within a data dictionary. The motivation for doing so would have been to 
provide rules adaptable to a target message format, thereby improving data 
mapping providing easier data manipulation. Therefore it would have been 
obvious to combine the teachings of Yehia with Tomm for the benefits of 
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providing an editor to make changes within a data dictionary for mapping target 
messages, thereby providing easier data manipulation and conversion between 
messages. 

// Is noted that any citation [[s]] to specific, pages, columns, lines, or figures in the prior art 
references and any interpretation of the references should not be considered to be limiting in any way. 
A reference is relevant for all it contains and may be relied upon for all that it would have reasonably 
suggested to one having ordinary skill in the art. [[See, MPEP 2123]] 

Response to Arguments 

10. Applicants arguments filed March 2, 2006 have been fully considered but they 
are not persuasive. The applicant states: 

This is quite different from the present invention which is aimed at a system for automatically generating 
message validation and transformation software from rules input by a user using a structured editor, (pg 1) 

The system of the present invention is significantly different in that the goal is to transform messages from a 
format used by one party (party A) to another format used by another party (party B). Once transformed the 
message can be sent to party B and the system of party B can implement the request in the message 
without additional processing, (pg 1) 

Nothing in Yehia teaches or suggest the generation of message validation and transformation software from 
a set of rules input using a structured editor, (pg 2) 

However the examiner respectfully disagrees. Yehia discloses the use of a user 
interface that allows trading partners to enter coordination rules (paragraph 76). The 
XSLT or XSL is used to enforce the rules or perform the validation. The use of a style 
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Sheet in general is "XML Stylesheet Language for Transformations. An XSL conversion tool that 
defines a set of rules that changes the structure of an XML document into an XML document of another 
structure." (Google: Define XSLT). Applicant states that the invention is significantly 
different because it transforms messages from a format A to a different format B. Using 
the broadest reasonable interpretation including what is known in the art, a style sheet 
is used to convert a document from format A to format B. The editing of the contracts is 
done using an editor because the contracts itself can be described in word format (see 
paragraphs 145 and 146). However the examiner believed that the Tomm reference 
better addresses these points. For example claim 1 , figure 3 of the Tomm reference 
clearly shows that the source message in a source format is converted to a target 
message in a target format. In addition Tomm Explicitly uses an editor to edit the 
structured rules (column 5, lines 25-40) Tomm states "an editor that allows the user to 
create a suitable rule is invoked...". As described in the specification paragraph 16, 
Yehia performs the same steps which involve a message in XML format and validation 
of that message using a style sheet. Applicant argues claim 15: 

The word processing formatted documents in Yehia are contract templates that are used to enter into 
contracts between companies and do not represent a pre-existing database of business niles related to the 
validation and transformation of messages from one format to another, (pg 2) 

However the examiner respectfully disagrees. Fig 27 & paragraphs 272-278 of Yehia 
discloses a rule & rule data repository that can be updated by a client. Applicant Argues 
claim 18: 

Applicant submit that although testing is mentioned there is no discussion of generating a set of test 
messages, (pg 3) 
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However the examiner respectfully disagrees. Since the messages undergo validation 
the testing of the business rules described by Abrari inherently includes testing of 
messages that are directly affected by the business rules. Applicant argues claim 29: 

Applicant submit that these paragraphs do not teach or suggest such a project interface but rather are 
concerned with the business mle input device, (pg 2) 

However the examiner respectfully disagrees. Fig 7 and paragraph 46 of Abrari 
discloses an interface containing all the structured files (see numeral 704). Applicant 
argues claim 28: 

Applicant submit that this section of column 5 describes the method of selecting a mapping mle using an 
auto-mapping process and does not teach or suggest the pruning of the data dictionary claimed in claim 28. 
(P9 3) 

However the examiner respectfully disagrees. Tomm states "an editor that allows the 
user to create a suitable rule is invoked" (column 5, lines 35-36). Therefore it inherently 
includes the pruning or removal of definitions within the data dictionary since the user is 
allowed to perform the step of editing. 

Many of the inventive features claimed and described by applicant are better addressed 
by the Tomm reference, however in order to expedite the prosecution of the case, those 
arguments are addressed within this section. 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as 
set forth in 37 CFR 1 .136(a). A shortened statutory period for reply to this final action is 
set to expire THREE MONTHS from the mailing date of this action. In the event a first 
reply is filed within TWO MONTHS from the mailing date of this final action and the 
advisory action is not mailed until after the end of the THREE-MONTH shortened 
statutory period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated 

from the mailing date of the advisory action. In no event, however, will the statutory 
period for reply expire later than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Manglesh M. Patel whose telephone number is (571) 

272- 5937. The examiner can normally be reached on M,F 8:30-6:00 T,TH 8:30-3:00 
Wed 8:30-7:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Stephen S. Hong can be reached on (571)272-4124. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 

273- 8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

Manglesh M. Patel 
Patent Examiner 
May 05, 2006 





CESAR PAULA 
PRIMARY EXAMINER 



